Header di Sicurezza Web: Content Security Policy e Esecuzione di JavaScript

Nel complesso panorama digitale di oggi, la sicurezza delle applicazioni web è fondamentale. Una delle difese più efficaci contro vari attacchi, in particolare il Cross-Site Scripting (XSS), è l'uso degli Header di Sicurezza Web. Tra questi, la Content Security Policy (CSP) si distingue come un potente meccanismo per controllare le risorse che un browser è autorizzato a caricare per una determinata pagina. Questo articolo fornisce una guida completa per comprendere e implementare efficacemente la CSP al fine di proteggere le vostre applicazioni web e i vostri utenti.

Comprendere gli Header di Sicurezza Web

Gli Header di Sicurezza Web sono header di risposta HTTP che forniscono istruzioni al browser su come comportarsi durante la gestione di determinati tipi di contenuto. Sono una parte cruciale di una strategia di difesa approfondita (defense-in-depth), che lavora insieme ad altre misure di sicurezza per mitigare i rischi.

Alcuni degli header di sicurezza web più comunemente utilizzati includono:

• Content Security Policy (CSP): Controlla le risorse che lo user agent è autorizzato a caricare.
• HTTP Strict Transport Security (HSTS): Forza i browser a utilizzare HTTPS.
• X-Frame-Options: Protegge dagli attacchi di Clickjacking.
• X-Content-Type-Options: Previene le vulnerabilità di MIME-sniffing.
• Referrer-Policy: Controlla quante informazioni sul referrer debbano essere incluse nelle richieste.
• Permissions-Policy (precedentemente Feature-Policy): Permette un controllo granulare sulle funzionalità del browser.

Questo articolo si concentra principalmente sulla Content Security Policy (CSP) e sul suo impatto sull'esecuzione di JavaScript.

Cos'è la Content Security Policy (CSP)?

La CSP è un header di risposta HTTP che consente di definire una whitelist di fonti da cui il browser è autorizzato a caricare risorse. Ciò include JavaScript, CSS, immagini, font e altri asset. Definendo esplicitamente queste fonti attendibili, è possibile ridurre significativamente il rischio di attacchi XSS, in cui script dannosi vengono iniettati nel vostro sito web ed eseguiti nel contesto dei browser dei vostri utenti.

Pensate alla CSP come a un firewall per il vostro browser, ma invece di bloccare il traffico di rete, blocca l'esecuzione di codice non attendibile.

Perché la CSP è Importante per l'Esecuzione di JavaScript?

JavaScript è un linguaggio potente che può essere utilizzato per creare esperienze web dinamiche e interattive. Tuttavia, la sua flessibilità lo rende anche un obiettivo primario per gli aggressori. Gli attacchi XSS spesso comportano l'iniezione di codice JavaScript dannoso in un sito web, che può poi essere utilizzato per rubare le credenziali degli utenti, reindirizzare gli utenti a siti di phishing o deturpare il sito web.

La CSP può prevenire efficacemente questi attacchi limitando le fonti da cui JavaScript può essere caricato ed eseguito. Per impostazione predefinita, la CSP blocca tutto il JavaScript inline (codice all'interno dei tag <script>) e il JavaScript caricato da domini esterni. È quindi possibile abilitare selettivamente le fonti attendibili utilizzando le direttive CSP.

Direttive CSP: i Mattoni della Vostra Policy

Le direttive CSP definiscono i tipi di risorse che possono essere caricate e le fonti da cui possono essere caricate. Ecco alcune delle direttive più importanti:

• default-src: Serve come fallback per altre direttive di fetch. Se una direttiva specifica non è definita, viene utilizzata default-src.
• script-src: Specifica le fonti consentite per il codice JavaScript.
• style-src: Specifica le fonti consentite per i fogli di stile CSS.
• img-src: Specifica le fonti consentite per le immagini.
• font-src: Specifica le fonti consentite per i font.
• media-src: Specifica le fonti consentite per i file audio e video.
• object-src: Specifica le fonti consentite per i plugin (es. Flash).
• frame-src: Specifica le fonti consentite per i frame (<frame>, <iframe>).
• connect-src: Specifica le origini consentite per le richieste di rete (es. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Limita gli URL che possono essere utilizzati nell'elemento <base> di un documento.
• form-action: Limita gli URL a cui i moduli possono essere inviati.
• upgrade-insecure-requests: Indica al browser di aggiornare tutti gli URL non sicuri (HTTP) a URL sicuri (HTTPS).
• block-all-mixed-content: Impedisce al browser di caricare risorse tramite HTTP quando la pagina è caricata su HTTPS.

Ogni direttiva può accettare una varietà di espressioni di fonte, tra cui:

• *: Consente risorse da qualsiasi fonte (generalmente non raccomandato).
• 'self': Consente risorse dalla stessa origine (schema, host e porta) del documento.
• 'none': Non consente risorse da nessuna fonte.
• 'unsafe-inline': Consente l'uso di JavaScript e CSS inline (fortemente sconsigliato).
• 'unsafe-eval': Consente l'uso di eval() e funzioni correlate (fortemente sconsigliato).
• 'unsafe-hashes': Consente specifici gestori di eventi inline basati sul loro hash SHA256, SHA384 o SHA512 (usare con cautela).
• data:: Consente URI data: (es. immagini inline codificate in base64).
• https://example.com: Consente risorse dal dominio specificato (e opzionalmente porta) tramite HTTPS.
• *.example.com: Consente risorse da qualsiasi sottodominio di example.com.
• nonce-{random-value}: Consente specifici script o stili inline che hanno un attributo nonce corrispondente (raccomandato per il codice inline).
• sha256-{hash-value}: Consente specifici script o stili inline che hanno un hash SHA256 corrispondente (alternativa ai nonce).

Implementare la CSP: Esempi Pratici

Ci sono due modi principali per implementare la CSP:

1. Header HTTP: Inviare l'header Content-Security-Policy nella risposta HTTP. Questo è il metodo preferito.
2. <meta> Tag: Usare un tag <meta> nella sezione <head> del documento HTML. Questo metodo ha delle limitazioni e generalmente non è raccomandato.

Usare l'Header HTTP

Per impostare l'header CSP, è necessario configurare il proprio server web. I passaggi esatti varieranno a seconda del server (es. Apache, Nginx, IIS).

Ecco alcuni esempi di header CSP:

CSP di Base

Questa policy consente solo risorse dalla stessa origine:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Consentire Risorse da Domini Specifici

Questa policy consente JavaScript da https://cdn.example.com e immagini da https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Usare i Nonce per gli Script Inline

Questa policy consente script inline che hanno un attributo nonce corrispondente:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

Nel vostro HTML:

            <script nonce="rAnd0mN0nc3">
 // Your inline script
</script>
            

              
                Copy
              
            
          

Nota: Il valore del nonce dovrebbe essere generato casualmente per ogni richiesta per impedire agli aggressori di aggirare la CSP.

Usare gli Hash per gli Script Inline

Questa policy consente specifici script inline basati sul loro hash SHA256:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

Per generare l'hash SHA256, è possibile utilizzare una varietà di strumenti online o utility a riga di comando (es. openssl dgst -sha256 -binary input.js | openssl base64).

Usare il Tag <meta>

Sebbene non sia raccomandato per policy complesse, il tag <meta> può essere utilizzato per impostare una CSP di base. Ad esempio:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Limitazioni del Tag <meta>:

• Non può essere utilizzato per specificare la direttiva report-uri.
• Non è supportato tanto ampiamente quanto l'header HTTP.
• Meno flessibile e più difficile da gestire per policy complesse.

Modalità CSP Report-Only

Prima di applicare una CSP, è fortemente raccomandato l'uso dell'header Content-Security-Policy-Report-Only. Questo permette di monitorare l'impatto della vostra policy senza bloccare effettivamente alcuna risorsa. Il browser segnalerà eventuali violazioni a un URL specificato, consentendovi di perfezionare la vostra policy prima di distribuirla in produzione.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

Dovrete configurare un endpoint lato server (es. /csp-report) per ricevere ed elaborare i report CSP. Questi report sono tipicamente oggetti JSON che contengono informazioni sulla direttiva violata, l'URI bloccato e altri dettagli rilevanti.

Errori Comuni della CSP e Come Evitarli

Implementare la CSP può essere impegnativo, ed è facile commettere errori che possono indebolire la vostra sicurezza o compromettere il funzionamento del vostro sito web. Ecco alcune trappole comuni da evitare:

• Usare 'unsafe-inline' e 'unsafe-eval': Queste direttive disabilitano essenzialmente le protezioni offerte dalla CSP e dovrebbero essere evitate ogni volta che è possibile. Usate nonce o hash per gli script inline ed evitate di usare eval().
• Usare *: Consentire risorse da qualsiasi fonte vanifica lo scopo della CSP. Siate il più specifici possibile quando definite la vostra policy.
• Non testare a fondo: Testate sempre la vostra CSP in modalità report-only prima di applicarla. Monitorate i report e modificate la vostra policy secondo necessità.
• Configurare in modo errato la report-uri: Assicuratevi che il vostro endpoint report-uri sia configurato correttamente per ricevere ed elaborare i report CSP.
• Non aggiornare la CSP: Man mano che il vostro sito web si evolve, la vostra CSP potrebbe dover essere aggiornata per riflettere i cambiamenti nelle dipendenze delle risorse.
• Policy eccessivamente restrittive: Policy troppo restrittive possono compromettere il funzionamento del vostro sito web e frustrare gli utenti. Trovate un equilibrio tra sicurezza e usabilità.

CSP e Librerie di Terze Parti

Molti siti web si affidano a librerie e servizi di terze parti, come CDN, fornitori di analisi e widget di social media. Quando si implementa la CSP, è importante considerare queste dipendenze e assicurarsi che la vostra policy consenta loro di caricare le risorse correttamente.

Ecco alcune strategie per la gestione delle librerie di terze parti:

• Inserire esplicitamente nella whitelist i domini dei fornitori di terze parti attendibili: Ad esempio, se utilizzate jQuery da una CDN, aggiungete il dominio della CDN alla vostra direttiva script-src.
• Usare la Subresource Integrity (SRI): L'SRI consente di verificare che i file caricati da fonti di terze parti non siano stati manomessi. Per usare l'SRI, è necessario generare un hash crittografico del file e includerlo nel tag <script> o <link>.
• Considerare di ospitare le librerie di terze parti sul proprio server: Questo vi dà un maggiore controllo sulle risorse e riduce la vostra dipendenza da fornitori esterni.

Esempio con SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP e Single-Page Application (SPA)

Le SPA si basano spesso pesantemente su JavaScript e sulla generazione dinamica di codice, il che può rendere più difficile l'implementazione della CSP. Ecco alcuni suggerimenti per proteggere le SPA con la CSP:

• Evitare di usare 'unsafe-eval': Le SPA utilizzano spesso motori di templating o altre tecniche che si basano su eval(). Considerate invece l'utilizzo di approcci alternativi che non richiedono eval(), come i template precompilati.
• Usare nonce o hash per gli script inline: Le SPA spesso iniettano codice JavaScript dinamicamente. Usate nonce o hash per garantire che venga eseguito solo codice attendibile.
• Configurare attentamente la direttiva connect-src: Le SPA effettuano spesso richieste API a vari endpoint. Assicuratevi di inserire nella whitelist solo i domini necessari nella direttiva connect-src.
• Considerare l'utilizzo di un framework consapevole della CSP: Alcuni framework JavaScript forniscono un supporto integrato per la CSP, rendendo più facile implementare e mantenere una policy sicura.

CSP e Internazionalizzazione (i18n)

Quando si sviluppano applicazioni web per un pubblico globale, è importante considerare l'impatto della CSP sull'internazionalizzazione (i18n). Ecco alcuni fattori da tenere a mente:

• Content Delivery Network (CDN): Se utilizzate una CDN per distribuire gli asset del vostro sito web, assicuratevi di inserire i domini della CDN nella whitelist della vostra CSP. Considerate l'utilizzo di CDN diverse per regioni diverse per ottimizzare le prestazioni.
• Font Esterni: Se utilizzate font esterni (es. Google Fonts), assicuratevi di inserire i domini dei fornitori di font nella whitelist della vostra direttiva font-src.
• Contenuti Localizzati: Se servite versioni diverse del vostro sito web per lingue o regioni diverse, assicuratevi che la vostra CSP sia configurata correttamente per ogni versione.
• Integrazioni di Terze Parti: Se vi integrate con servizi di terze parti specifici per determinate regioni, assicuratevi di inserire i domini di tali servizi nella whitelist della vostra CSP.

Best Practice per la CSP: Una Prospettiva Globale

Ecco alcune best practice generali per l'implementazione della CSP, tenendo conto di una prospettiva globale:

• Iniziare con una policy restrittiva: Iniziate con una policy che blocca tutto per impostazione predefinita e poi abilitate selettivamente le fonti attendibili.
• Usare prima la modalità report-only: Testate la vostra CSP in modalità report-only prima di applicarla per identificare potenziali problemi.
• Monitorare i report CSP: Rivedete regolarmente i report CSP per identificare potenziali vulnerabilità di sicurezza e perfezionare la vostra policy.
• Usare nonce o hash per gli script inline: Evitate di usare 'unsafe-inline' e 'unsafe-eval'.
• Essere specifici con le liste di fonti: Evitate di usare caratteri jolly (*) a meno che non sia assolutamente necessario.
• Usare la Subresource Integrity (SRI) per le risorse di terze parti: Verificate l'integrità dei file caricati dalle CDN.
• Mantenere la CSP aggiornata: Rivedete e aggiornate regolarmente la vostra CSP per riflettere i cambiamenti nel vostro sito web e nelle dipendenze.
• Formare il vostro team: Assicuratevi che i vostri sviluppatori e il team di sicurezza comprendano l'importanza della CSP e come implementarla correttamente.
• Considerare l'uso di un generatore o di uno strumento di gestione della CSP: Questi strumenti possono aiutarvi a creare e mantenere più facilmente la vostra CSP.
• Documentare la CSP: Documentate la vostra policy CSP e le ragioni alla base di ogni direttiva per aiutare i futuri sviluppatori a comprenderla e mantenerla.

Conclusione

La Content Security Policy è un potente strumento per mitigare gli attacchi XSS e migliorare la sicurezza delle vostre applicazioni web. Definendo attentamente una whitelist di fonti attendibili, potete ridurre significativamente il rischio di esecuzione di codice dannoso e proteggere i vostri utenti da eventuali danni. L'implementazione della CSP può essere impegnativa, ma seguendo le best practice delineate in questo articolo e considerando le esigenze specifiche della vostra applicazione e del vostro pubblico globale, potete creare una policy di sicurezza robusta ed efficace che protegga il vostro sito web e i vostri utenti in tutto il mondo.

Ricordate che la sicurezza è un processo continuo e la CSP è solo un pezzo del puzzle. Combinate la CSP con altre misure di sicurezza, come la validazione dell'input, la codifica dell'output e regolari audit di sicurezza, per creare una strategia di difesa approfondita completa.

Risorse Aggiuntive

• Content Security Policy (CSP) - MDN Web Docs
• Valutatore CSP
• Content-Security-Policy.com